1. Field of the Invention
The present invention relates to a digital rights management (DRM) method, device and system, and more particularly, to a method, device and system for moving a rights object into another device in a digital rights management system.
2. Discussion of the Background Art
Digital Rights Management (DRM) is a technology for safely protecting and systematically managing a rights object for digital contents (e.g., music, movies, literature, images, etc.). DRM prevents unauthorized and/or illegal copying of digital contents. DRM also provides for the acquisition of rights object (RO) for DRM contents, production and distribution of DRM contents, and protection and management for a series of usage processes.
FIG. 1 is an exemplary view illustrating a move of a DRM rights object (hereinafter, ‘RO’).
As seen in FIG. 1, a conventional digital rights management system may include a rights issuer (RI) 50, a source device 11, and a target device 12.
The rights issuer (RI) 50 issues a rights object (RO) required for using protected contents produced by a contents issuer (not shown).
The source and target devices 11, 12 may include a DRM agent. Commonly, the DRM agent in the source and target devices 11, 12 receives the protected contents and the RO, and converts the protected contents into a form that is usable in the relevant device. Furthermore, the DRM agent analyzes the permission and/or constraint included in the RO to control a use of the contents.
A rights object move protocol known as a 2-pass Move Device RO protocol is illustrated in FIG. 1. The 2-pass Move Device RO protocol is a protocol for moving a rights object (RO) issued by the RI 50 or LRM from the source device 11 to the target device 12, as defined in OMA SCE Enabler v1.0.
It is assumed that the source device 11 carried out a registration protocol in advance, and the RI 50 has a right RI context for the source device 11. After registration, the following steps may be taken.
The RI 50 transmits a move request trigger message, for instance, a Move Device RO Trigger message, to the source device 11 to start a move of the rights object (RO).
The source device 11 transmits a move request message, for instance, a Move Device RO Request message, to the RI 50 to request a move of the rights object (RO). At this time, the rights object (RO) has been issued by the RI 50. If the rights object (RO) is issued by another RI, then the move request message would be transmitted to the another RI.
Optionally, the move request message may include a certificate chain to transfer a certificate of the source device 11 and the source device's associated certificate.
3) Then, the RI 50 examines the move request message. At this time, the RI 50 checks whether or not the rights object (RO) can be moved.
Optionally, the RI 50 may transmit an Online Certificate Status Protocol (OCSP) Request message to an OCSP responder 60 to request a verification of the certificate chain within the move request message.
4) The OCSP responder 60 verifies the certificate chain, and transmits the OCSP Response message to the RI 50.
5) Then, the RI 50 transmits a move request response message, for instance, Move Device RO Response message, to approve a move of the rights object (RO).
6) Subsequently, the RI 50 and the target device 12 carry out a rights object (RO) move procedure. Here, the move procedure includes issuing a new RO to the target device 12.
FIG. 2 is another exemplary view of a move of a rights object (RO) (i.e., for a user domain) according to the related art.
A user domain is a domain in which devices previously set are regarded to be owned by one person and used by sharing the rights object (RO). A domain authority (hereinafter, ‘DA’) and/or DA enforcement agent (hereinafter, ‘DEA’), though not shown, may be used to manage such a user domain.
A procedure for moving a rights object (RO) of the user domain is same as the procedure as illustrated in FIG. 1.
In the move of a rights object (RO) as described above, the source device 11 transmits a move request message to the RI 50. However, if the move request message transmitted from the source device 11 is intercepted or hijacked by a third person, the intercepted move request message is resent to the RI 50. Accordingly, there is a problem that the rights object (RO) may be repeatedly issued to the target device 12.
This problem is caused because a rights object move protocol in the related art, e.g., the previously described 2-pass Move Device RO protocol, is designed in such that even if multiple move request messages including the same ID (for instance, ROID) are received, all the messages are processed to support a partial (or a specific portion) move of the rights object (RO). Here, intercepting, by a mal-intended terminal, a move request message and resending the intercepted movement request message repeatedly to the RI 50 is called a replay, and such a type of attack is called a replay attack. However, during a replay attack, the third person performing an intercept cannot change the contents of the message at his own discretion because the move request message is digitally signed.
However, according to the related art, when the source device 11 has transmitted the move request message but the RI 50 has not received it, the source device 11 may resend the message. However, in the related art, it is not defined how the source device 11 constructs the move request message at the time of the resending, or in what method the RI 50 distinguishes the resent move request message from an initial move request message to process it. Hereinafter, the resending is called a retry.
What is required, as discovered by the present inventors, is a method, device and system for solving the previously described problems, along with other problems.